@johnslavik, I'm not sure I agree -- I don't think we should devote too much space in the typing docs for this. As @JelleZijlstra said on the issue, exactly what kind of objects these symbols are at runtime is an implementation detail that most users shouldn't worry about. Giving too much space in the docs for these details would give the incorrect impression that these are things that users need to understand, when they're almost always not.

Thanks @aisk for the PR, and @AlexWaygood for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

GH-143696 is a backport of this pull request to the 3.14 branch.

GH-143697 is a backport of this pull request to the 3.13 branch.

Thanks @aisk!

This broke references to the TypedDict class attributes such as __total__. They are still documented, but as top level attributes of the typing module, e.g. https://docs.python.org/3/library/typing.html#typing.__total__:

And so breaks Sphinx cross references.

This broke references to the TypedDict class attributes such as __total__. They are still documented, but as top level attributes of the typing module, e.g. docs.python.org/3/library/typing.html#typing.__total__:

Ah, because functions cannot have attributes, according to Sphinx? That's too bad. Great catch @Viicos.

@aisk, would you be able to make a PR reverting just the change from .. class:: TypedDict to .. function:: TypedDict? I think that's the only problematic bit of this PR, right?

Ah, because functions cannot have attributes, according to Sphinx? That's too bad.

Yeah that might be it. I'm wondering if it would make sense to document them as data elements instead, like some other special forms such as Annotated? This would be in line with what you mentioned Alex in your previous comment.

This broke references to the TypedDict class attributes such as __total__. They are still documented, but as top level attributes of the typing module, e.g. docs.python.org/3/library/typing.html#typing.__total__:

Ah, because functions cannot have attributes, according to Sphinx? That's too bad. Great catch @Viicos.

@aisk, would you be able to make a PR reverting just the change from .. class:: TypedDict to .. function:: TypedDict? I think that's the only problematic bit of this PR, right?

Oops, I've read this right after making that PR #143702

Yeah that might be it. I'm wondering if it would make sense to document them as data elements instead, like some other special forms such as Annotated? This would be in line with what you mentioned Alex in your previous comment.

That works for me if Sphinx renders it okay!

Yeah data makes sense to me. Whether they're classes or functions is an implementation detail that we should be free to change again later. data leaves it unspecified. (I'm not sure we need the versionchanged notes about changes from function to class either.)

@AlexWaygood Sorry for breaking this. I went to sleep after submitting this, so I only just saw the notification.

@johnslavik Thanks for fixing it!